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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

Please note that the present document is a revision to TR 102 542 [i.7], and has been converted to a Technical 
Specification (TS) because the language used in the document is akin to that of a Technical Specification (TS). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1 21 8 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Digital Video Broadcasting Project (DVB) is an industry-led consortium of broadcasters, manufacturers, network 
operators, software developers, regulatory bodies, content owners and others committed to designing global standards 
for the delivery of digital television and data services. DVB fosters market driven solutions that meet the needs and 
economic circumstances of broadcast industry stakeholders and consumers. DVB standards cover all aspects of digital 
television from transmission through interfacing, conditional access and interactivity for digital video, audio and data. 
The consortium came together in 1993 to provide global standardisation, interoperability and future proof 
specifications. 

The present document is part 1 of a multi-part deliverable covering the GuideUnes for the implementation of 
DVB-IPTV Phase 1 specifications, as identified below: 

Part 1: "Core IPTV Functions"; 

Part 2: "Broadband Content Guide (BCG) and Content on Demand"; 
Part 3: "Error Recovery"; 

Sub-part 1: "Overview of DVB-IPTV Error Recovery"; 

Sub-part 2: "Application Layer - Forward Error Correction (AL-FEC)"; 

Sub-part 3: "Retransmission (RET)"; 
Part 4: "Remote Management and Firmware Update"; 
Part 5: "Content Download Service (CDS)". 
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Scope 



The present document is designed as a companion document to help implement the DVB-IPTV Phase 1 version 4: 
Transport of MPEG2-TS Based DVB Services over IP Based Networks [1], which is referred to as the DVB-IPTV 
handbook. 

The present document is the part 1 of the Guidelines and is focusing on the core IPTV functions. Other parts present 
other aspects of the DVB-IPTV technologies. 

The present document is organized in separate sections in the order of the boot-up sequence of the HNED rather than in 
the same section structure as the DVB-IPTV handbook. Each clause deals with a specific aspect of the DVB-IPTV 
technology, and offers explanations and examples not found in the DVB-IPTV handbook. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 102 034 (Vl.4.1): "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based 

DVB Services over IP Based Networks". 

[2] ETSI TS 101 154 (Vl.8.1): "Digital Video Broadcasting (DVB); Specification for the use of Video 

and Audio Coding in Broadcasting Applications based on the MPEG-2 Transport Stream". 

[3] ETSI TS 102 824 ( V 1 . 1 . 1 ): "Digital Video Broadcasting (DVB); Remote Management and 

Firmware Update System for DVB IP Services". 

[4] SMPTE Specification 2022-1: "Forward Error Correction for Real-time Video/Audio Transport 

Over IP Networks". 

[5] DVB BlueBook A109: "DVB-HN (Home Network) Reference Model Phase 1 ". 

[6] Broadband Forum TR-069 Amendment 2: "CPE WAN Management Protocol", December 2007. 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i. 1 ] IETF RFC 3927: "Dynamic Configuration of IPv4 Link-Local Addresses" . 

[i.2] IETF RFC 3203: "DHCP reconfigure extension". 
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[i.3] IEEE P802. 1 1 -REVma/D6.0, 2006: "Unapproved Draft Standard for Information Technology - 

Telecommunications and information exchange between systems- Local and metropolitan area 
network- Specific requirements; Part 11: Wireless LAN Medium Access Control (MAC) and 
Physical Layer (PHY) specifications". 

NOTE: This document reflects the combining of the 2003 Edition of 802.11 plus the 802.1 Ig, 802.1 Ih, 802.111 
and 802.11J Amendments) (Revision of IEEE Std 802.11-1999). 



[i.4] 

[i.5] 
[i.6] 
[i.7] 

[i.8] 



IEEE 802. Id (2004): "IEEE Standard for Local and metropolitan area networks: Media Access 
Control (MAC) Bridges". 

IETF RFC 3376: "Internet Group Management Protocol, Version 3". 

IETF RFC 1 1 12: "Host extensions for IP multicasting". 

ETSI TR 102 542: "Digital Video Broadcasting (DVB); GuideHnes for DVB IP Phase 1 
Handbook". 

ETSI TS 102 542-4: "Digital Video Broadcasting (DVB); Guidelines for the implementation of 
DVB-IPTV Phase 1 specifications; Part 4: Remote Management and Firmware Update Services". 



3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ALG Application Level Gateway 

BCG Broadband Content Guide 

BiM Binary MPEG format for XML 

CPE Customer Premises Equipment 

CRLF Carriage Return Line Feed 

DHCP Dynamic Host Configuration Protocol 

DNG Digital Network Gateway 

DSCP Differentiated Services CodePoint 

DSL Digital Subscriber Line 

DVB Digital Video Broadcasting 

DVBSTP DVB SD&S Transport Protocol 

FEC Forward Error Connection 

FUS Firmware Update System 

FUSS FUS Stub file 

HN Home Network 

HNED Home Network End Device 

HTTP Hyper Text Transfer Protocol 

IEEE Institute of Electrical and Electronics Engineers 

IETF Internet Engineering Task Force 

IGMP Internet Group Management Protocol 

IP Internet Protocol 

IPI IP Infrastructure 

LAN Local Area Network 

LCN Logical Channel Numbers 

MPEG Moving Picture Experts Group 

MPTS Multi Program Transport Stream 

NAT Network Address Translation 

QRC Query/Response Channel 

RET RETransmission 

RFC Request For Comments 

RMs Remote Management System 

RTP Real-time Transport Protocol 

RTSP Real Time Streaming Protocol 

SD&S Service Discovery and Selection 

SI Service Information 

SPTS Single Program Transport Stream 
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TS 

UDP 

XML 



Transport Stream 
User Datagram Protocol 
extensible Markup Language 



Background to the Scenarios 



Figure 4. 1 shows the Home Reference Model for the DVB -IPX V phase 1, taken from the DVB-IPTV handbook (see TS 
102 034 [1], clause 4. L2). 



Delivery Network 
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Home Network 
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Home Network 
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Figure 4.1 : Home Reference Model (from TS 102 034 [1]) 

Figure 4.1 and the current version of the DVB-IPTV handbook [1] focuses only on the delivery of DVB-IPTV services 
over broadband delivery networks. DVB is working on enhanced home networking functionality which will for 
example allow an end user to access DVB content from several devices in the home. The Home Network Reference 
Model for this approach is provided in [5]. The protocols and functions to support this Home Network Reference Model 
will be defined in upcoming specifications and therefore not covered in the current version of the present document. 

The DVB-IPTV handbook only specifies the IPI-1 interface at the Home Network End Device (HNED). However, the 
specification of the IPI-1 interface also defines characteristics of the Home Network Segment between the HNED and 
the DNG, and in some cases what the DNG must deliver. 

The DVB-IPTV handbook intentionally does not attempt to specify where particular servers need to reside, for example 
the DHCP server. This means that no protocol is defined to operate solely on the home network segment. It also means 
that operation of one HNED is completely independent of the operation of another HNED in the same Home Network. 
Although multiple HNEDs in the same Home Network will share IP connectivity, there is no specific protocol defined 
in the DVB-IPTV handbook to allow them to exchange messages, or even know about the presence of each other. 

The DVB-IPTV handbook does not currently define the interface IPI-2 so any routing or translation scenario that may 
be required for interworking between Home Network Segments is outside of the scope of Phase 1 of the DVB-IPTV 
handbook. This means that many HNEDs can be connected to a single DNG, but multiple DNGs connected on the same 
network segment is not allowed. 
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Turning on and Booting an HNED 



The best way to describe how the DVB-IPTV handbook can be used is to go through what happens when you turn on an 
HNED. There are a number of steps in order to have: 

Physical/MAC Layer Connection. 

IP Layer connectivity via obtaining an IP Address. 

Connection to RMS or FUS to update firmware if necessary. 

Connection to the SD&S servers. 

Discovery of BCG information (optional). 

Content Selection. 

Streaming of the video content. 

5.1 Physical/IVIAC Layer Connection 

The physical and the link layers need to come up before anything else happens. The DVB-IPTV handbook requires an 
IEEE 802 based MAC layer with priority marking according to IEEE 802. Id [i.4] within the home network segment. 
These can be used by the network to help obtain the Quality of Service required for the streamed video content. 

5.2 IP Layer connectivity via obtaining an IP Address 

Once the link layer comes up, the HNED obtains the IP address from a DHCP server with the DVB mandatory DHCP 
options. The DVB-IPTV handbook specifies the minimum DHCP options required to allow the DHCP server to be 
simple enough to fit into a DNG or other product on the home network segment. 

DHCP does not currently specify a way to co-ordinate the address pools of multiple DHCP servers on a network. The 
DHCP client simply takes the first address offered to it but, normally, the closest available server. This means that 
multiple DHCP servers cannot be used on the same network to serve the HNED. 

The IP address assigned by the DHCP server will be different for each HNED on the same home network segment, but 
will be part of the same IP subnet. The use of private or public IP address space and size of the subnet mask is at the 
discretion of the Network Service Provider. 

NOTE: zero-configuration mechanism: 

Whilst the DVB-IPTV handbook proposes two ways for HNEDs to get an IP address: DHCP server or via 
RFC 3927 [i.l] (IETF zero configuration mechanism), DHCP server is the normal way. It is expected that 
the RFC 3927 [i.l] is only to be used in emergency where the DHCP server is down for some short-term 
reason. Running in zero-conf mode provides none or very little connectivity. Basically, the HNED does 
not have knowledge of a gateway device to send messages to external servers. Therefore the only possible 
scenario is to connect to multicast streams (provided the DNG allows IGMP messages to flow over to the 
access network): first to connect to an SD&S stream, then to connect to a live TV stream. 

5.2.1 Location of the DHCP Server - Bridged and Routed modes 

The following clauses detail the several IP connectivity modes that are allowed by the DVB-IPTV handbook. The 
location of the DHCP server (in the HN or in the access network) has an impact on the IP connectivity of the system. 
Furthermore, a DVB-IPTV system without DHCP server can provide limited but existing services. 
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5.2.1.1 



Bridged Mode 



In the bridged mode, the DHCP server is located on the external network, typical of some DSL, or most cable or 
Ethernet to the Home deployments. The DNG then acts as a bridge or DHCP "relay" to relay the DHCP messages to the 
external DHCP server as shown in figure 5.1. Please be aware that the DVB Class options must be preserved in this 

case. 
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Figure 5.1 : Home Network in bridged mode with remote DIHCP server 

In order to overcome problems with local DHCP servers and Address Translation, IPTV deployments in DSL networks 
often connect the HNED to a bridge port of the DNG which directly connects the HNED to the Access Network at the 
link layer below IP. The HNED is in this case within the IP address space of the Access Network and uses the DHCP 
server of the Access Network as shown in figure 5.2. A disadvantage is that the HNED is separate from the Home 
Network of the user which is connected via routed ports of the DNG. 
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Figure 5.2: IHome Networic in hybrid mode with remote DIHCP server 
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5.2.1.2 



Routed Mode 



In the routed mode, the DHCP server is located in the home, it will likely be on the DNG, a scenario typical of DSL. 
The most popular means of address assignment is to have the home in a private IP address space whilst the public 
interface has an IP address given by the network operator as shown in figure 5.3. The DNG uses Network Address 
Translation to change the IP addresses of the data from public to/from private address spaces. 
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Figure 5.3: Home Network in routed mode with local DHCP server 

There is the special case where the DHCP server is not present while the Home Network is in routed mode. This 
situation is not desirable, but can happen when the DHCP server is down. In this case, zero configuration is used for the 
HNEDs to get their IP address on their own. 
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Figure 5.4: Home Network in routed mode with local DHCP server 

5.2.2 Adding a New DHCP Class Option 

The DHCP Class IDs defined in the DVB-IPTV handbook are the minimum set needed to support the types of HNEDs 
originally supported in the commercial and technical requirements. The DVB-IPTV handbook allows these attributes to 
be added to by any DVB member. 

The Class ID is meant to help the DHCP server gives the appropriate IP address for the type of HNED. It is an insecure 
method but, for example, will allow a DHCP server to give a private address to one type of HNED and a public one to 
another. Since it provides the path to the FUS Stub file (FUSS) which provides information about the RMS and FUS for 
an HNED part of the information may be manufacturer specific. 
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Following is the procedure to add a new attribute: 

1) Contact the DVB Project Office via the web site or email with the following information: 

Name of the Class ID. 

Company name. 

Contact name, email address and phone number of the legal representative who is the signatory to the 
request. 

Contact name, email address and phone number of the technical representative for the request. 

Technical and Commercial motivation for the request. 

2) The DVB Project Office will optionally contact the company. 

3) The DVB Project Office will then notify the technical and legal representative of their decision. 

4) If the decision is positive then the class ID will be published on the DVB web site and, if possible, in the next 
maintenance revision of the DVB-IPTV handbook. 



5.3 FUS and RMS Discovery 



NOTE: In this clause, the term "HNED" is used. The update capability may extend to the DNG if the logical 
RMS and/or FUS client is incorporated into the device. 

The process for acquiring the FUS Stub file (FUSS) is described in TS 102 034 [1] clause 9, shown diagrammatically 
below in figure 5.5. Several DHCP options may be used to provide the information related to locating the FUSS file for 
a HNED and the process described in TS 102 034 [1] gives a sequence in which they should be tried. 

There should be a FUS Stub file for all supported HNEDs, but the decision as to whether to download and install the 
firmware available must be made by the HNED, for example the HNED should not install older versions of the 
firmware. 

After trying these options, if no FUSS is available it must be assumed that no FUS connection is needed, and the HNED 
should continue into the normal service discovery or remote management service connection process, as appropriate to 
the HNED. 
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Figure 5.5: Acquisition of FUS Stub file and identification of firmware update 

The process may yield different types of results according to the HNED status and to different scenarios, these are 
developed below. However, it is necessary for all HNEDs to go through the FUSS acquisition process as this enables 
the status of a HNED to be changed, enabling updates such as those described below: 

• to update a new HNED populated with default firmware to either full managed or unmanaged status; 

• the remote management authority to be changed for a managed HNED where the ProductClass and 
Hard ware Version are compatible; 

• to allow a managed HNED to be made unmanaged; 

• to allow an unmanaged HNED to be made to be managed. 

5.3.1 HNED managecj using BroacJbancJ Forum TR-069 methocjs 

Following the FUSS acquisition process for a managed HNED the RMS will be used to manage firmware updates 
possibly through the FUS and HNED configuration changes so the requirement is for the HNED to contact the RMS. 
This process will be described fully in the documentation specific to the RMS methods used, where the RMS is 
compliant with the Broadband Forum methods. This description is carried in section 3.1 of TR-069 [6]. 

The RMS can configure the entry into the FUS announcement service using the DVB extensions described in 
TS 102 824 [3]. 
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5.3.2 Unmanaged HNEDs 



In the case of an unmanaged HNED one of the options for locating the FUSS should give a result in the form of either a 
unicast or multicast URL. 



Transport protocol = multicast 
(DVBSTP) or unicast (HTTP(S)) 
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(DVBSTP) 
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(DVBSTP) or unicast (HTTP(S)) 




Link mechanisms Into 

RMS-FUS area 

Usage described in TS 

1 02 824 



Figure 5.6: Options for locating thie FUSS 

The URI provided in the FUS Stub file may be either unicast or multicast with the options below: 

• The unicast URL may: 

point directly to a file image for downloading from the FUS directly 
(e.g. http://download.cisco.com/STB-Software/fredl001.bin.). 

• The Multicast URL will be based on the "dvb-mcast" URI scheme as described in annex G.3 of 
TS 102 034 [1], and may: 

point directly to a file image for downloading from the FUS directly 
(e.g. dvb-mcast://download.cisco.com/STB-Software/fredl001.bin.); 

If SDP/SAP is used as the protocol may provide: 

■ location of the announcement message specific to the update image available; 

■ location of the entry point of the announcement message hierarchy, may be useful to point to wider 
populations (not completely populated ID info in FUSS); 

■ location of an intermediate pointer message based on wider targeting, may be useful to point to 
wider populations (not completely populated ID info in FUSS). 

If DVBSTP is used the protocol may provide: 

■ location of the XML description announcement message specific to the update image available. 

The HNED should be able to locate the firmware update using announcement description on the addresses provided. 
The detailed description of those operations is provided in TS 102 824 [3] and the associated guidelines in 
TS 102 542-4 [i.8]. 
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Where the address leads to the entry point of the announcement hierarchy or an intermediate pointer further navigation 
will be needed. The capability to associate a firmware update with a specific group of HNEDs can be supported at all 
these levels with different levels of flexibility. 



5.4 Content Discovery 



Now that the HNEDs have their IP address and that they have performed the FUS process (including firmware update if 
necessary), they start looking for the SD&S servers(s) to retrieve the service lists. Figure 5.7 shows several ordered 
steps that a HNED walks through to connect to the service providers. In figure 5.7, the DHCP DISCOVER/OFFER 
messages can be mutuahsed with the DHCP DISCOVER/OFFER from the FUS process, i.e. a single DHCP OFFER 
will be received with all information for FUS and SD&S discovery. 



DHCP 
server 



1. DHCP server sets the Domain Name option 

=> DNS S RV to the servers in the Domain Name Option 

2. DHCP server gives no Domain Name 

=>HNED connects to the lANA assigned multicast address 
224.0.23.14 



3. No ivjulticast data can be retrieved 

=>DNS SRV to the default server « services.dvb.org » 



4. Nothing has worked 

=> user configures manually the SD&S address 



DHCP DISCOVER 



DHCP OFFER, 
DomainName=w.x.y.z 



Contact DNS w.x.y.z 



DHCP OFFER 

No Domain Name 



Connectto 224.0.23.14 



HNED 



DHCP OFFER No DomainName 
Multicast Channel No Multicast Data 



Contact DNS services. dvb.org 



DHCP OFFER No DomainName 

Multicast Channel No Multicast Data 

DNS No Answer 



Figure 5.7: SD&S server Entry Point discovery order 

5.4.1 Content Discovery in Routed Mode witin Local DHCP Server 

The number of mechanisms reflects the different topologies of the service provider and in-home networks, and DNGs. 
For example, current DSL providers use DNGs with DHCP servers that sometimes do not support the DHCP Domain 
Name Option, so it is possible that the DHCP server in the DNG in the home will not support steps 1. 

However, the giaddr field will be set (it indicates the IP address of the gateway device). This means that with basic 
NAT feature on the gateway device, step 3 can be performed. The HNED can connect to the default DVB server 
(HNED 1 in figure 5.8), or better directly to a specific provider (HNED 2 - this happens when the HNED is coming 
from the content provider, so it knows the address of its server). 
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DVB 
server 



Content 
provider 




HNED 1 



HNED2 



Network 
IP@ space 



Private 
IP@ space 



Figure 5.8: Content discovery with DHCP server 

5.4.2 Content Discovery in Routed Mode witinout DHCP Server 

Whilst an HNED without a corresponding DHCP server is an abnormal situation, HNEDs may still retrieve the service 
lists. This is by using the DVB assigned multicast address (step 2 in figure 5.7). If the DNG forwards the IGMP 
messages from the HNEDs (this is a broadcast message on the Home Network Segment, so the gateway will receive it), 
and provided that the DNG forwards incoming multicast packets from the access network into the home, then the 
DVBSTP stream can be received by the HNED. It will then build the service list based on the content of this stream. 



DVB 
server 



Multicast 
DVBSTP 
stream 



IGMP join 




HNED 1 



HNED 2 



Network 
IP@ space 



Private 
IP@ space 



Figure 5.9: Content discovery without DHCP server 

Note that this solution may work for Live Media Broadcast Content only. Live Media Broadcast Content may require 
only an IGMP message to get the AV multicast stream, without RTSP protocol. Content on Demand will not be 
possible because it requires RTSP, and the HNED does not know where to send the RTSP message (no gateway 
identified). 
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5.5 



Content Selection 



With DVB-IPTV phase 1, there are basically three ways to access content: 

• Multicast stream selection only. 

• Multicast stream selection plus RTSP. 

• Unicast stream with RTSP. 

The first two steps are for live TV content while the latter is for content on demand or Media Broadcast with Trick 
Modes services. For Live TV, the RTSP messages are not mandatory; it is perfectly possible for the HNED to just join 
the corresponding multicast group. 

5.5.1 Content Selection in Routed Mode with Local DHCP Server 

The multicast join message is sent on the HN, and the gateway forwards it to the access network. Thus the Live TV 
stream can be received by the HNED. 



Content 
provider 



Multicast 
LiveTV. 
stream 




IGMP join 



Network 
IP@ space 



Private 
IP@ space 



HNED 1 



HNED 2 



Figure 5.10:IGMP live content selection 

If the RTSP protocol is used, the gateway needs to provide RTSP ALG (Application Level Gateway) feature: this ALG 
replaces into the RTSP message payload the values of the IP address and UDP port given by the HNED by the public 
IP address of the gateway and an available UDP port. This RTSP message will be sent before doing the multicast join. 
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provider 
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LiveTV. 
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Figure 5.11 : RTSP live content selection 
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Finally, in case of unicast streaming, no multicast join is necessary but the gateway still needs its RTSP ALG feature. 



Unicast 

CoD 
stream 



Content 
provider 




HNED 1 



HNED2 



Network 
IP@ space 



Private 
IP@ space 



Figure 5.12: Content on Demand selection 

5.5.2 Content Selection in Routed Mode witinout DHCP Server 

Again, as in clause 5.4.2, this may work provided that the DNG forward the multicast report message, and forward 
incoming multicast packets in the home. The only possibility with this configuration is to connect to a Live TV stream 
without RTSP protocol. 



Multicast 
LiveTV. 
stream 



Content 
provider 




HNED1 



IGMP join 



HNED 2 



Network 
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Figure 5.13: Live content selection 



5.6 Cellld Configuration 



Some IPTV services are subject to regionalization, i.e. they are available only in specific geographical areas. The 
regionalization information is present in the description of the IPTV service or package (see clause 6.4.2 of the present 
document) in the form of a pair Country/Cellld. The Cellld is the string parameter within the "Cell" XML tag. 

While the regionalization of an IPTV service is dependent on the IPTV service provider (definition of the cell 
boundaries and identification names), the location of the HNED is dependent on the network provider (physical 
connection to the IP network). Thus, the DVB-IPTV mechanism to retrieve the cellld is based on such location 
information that has to be matched against IPTV service provider regionalization information. 
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In order to know which IPTV service or package is available, the HNED has to know its own pair Country/Cellld. The 
HNED retrieves first its location parameters. This is done thanks to the DHCP option 99 (Civic Address). This DHCP 
option provides the country code and a set of Civic Address parameters. The country code will be matched as-is against 
the country code XML element of the IPTV service and package. The cellld is retrieved in two possible ways: 

• Pull mode: the HNED sends a HTTP POST request to the IPTV service provider, which returns back the 
assigned cellld. The HTTP POST includes all Civic Address elements as received within the DHCP option 99, 
following the Cell XML element structure. 

• Push mode: the HNED connects to the Regionalization Discovery Record for the IPTV service provider, 
parses it to retrieves its cellld. As the Regionalization Discovery Record does not contain necessarily all Civic 
Address parameters, the match is done only on parameters that are present in the record structure. 

In this way, the HNED does not care about the meaning of the Civic Address parameter, this is dealt with between the 
Network Provider and the IPTV service provider. The IPTV Service Provider can ask the Network Provider to include 
private parameter (Civic Address Type 132). 



6 SD&S Service Discovery 

6.1 Push and Pull modes 

Once one of the ways of selecting the Service Discovery entry points has been chosen, the HNED knows the entry 
points and can access the SD&S server either in multicast or unicast way. For each entry point, the HNED collects the 
Service Provider Discovery information. 

The Service Provider Discovery Information may be (according to the IP address class of the Service Discovery entry 
point): 

• Multicast (Push model): The HNED sends an IGMP Report request to a multicast address in order to 
subscribe to this multicast group. The content of the "Provider" XML file is carried by the DVBSTP protocol 
with a payload id value set to 0x01 (see table 1: Payload ID values of TS 102 034 [1]). 

• Retrieved on request (Pull model). In this case, the HNED sends a HTTP request: 

'GET /dvb/sdns/sp_discovery?id=ALL HTTP/1.1' CRLF 
'Host: ' <host> CRLF 



'GET /dvb/sdns/sp_discovery?id=<DomainWame> HTTP/1.1' CRLF 
'Host: ' <host> CRLF 

Both models are supported. 

The HNED gets thus the Service Providers' list and their Push or Pull offers. The HNED selects the Push [Multicast 
IP address (IGMP), content of XML file carried by DVBSTP] or Pull (in this case, it is done through a HTTP request) 
offers of its Service Provider. 

For information, the Payload ID values of the different SD&S services are shown in table 1 of TS 102 034 [1]. 

Service discovery information is represented as XML records (examples are given hereafter). In order to be managed 
efficiently by the HNED, SD&S records are fragmented into a number of smaller units, called Segments. Segments may 
be transported uncompressed or compressed using BiM. 

BiM compression reduces the size of the SD&S XML records significantly, therefore its use is recommended in 
constrained environments. When the network provider uses BiM compression, it shall also make available 
uncompressed Segments (in Push, Pull or both modes). 
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6.2 Strategies for SD&S Service Discovery 

6.2.1 Choosing between push and pull modes 

Multicast and HTTP sources for SD&S information are extracted first from the Entry Point Discovery process and then 
from Service Provider descriptions. For each of these steps, the HNED may find either only one transport model 
provided or both. When both are provided, they convey exactly the same information (XML records) so there is a 
choice to use one method or the other. Using the HTTP mode has the drawback of increasing the server load 
proportionally to the number of HNED on the network, which can be millions. Multicast mode has the drawback of a 
potential delay of 30 seconds in order to scan a complete carrousel cycle. A general recommendation for "fair 
behaviour" of the HNED would be then to prefer multicast mode when no specific reason asks for an immediate 
acquisition of some information (which is however never guaranteed) and reserve the use of HTTP for infrequent 
situations where the application needs to provide up-to-date information quickly to the end user. 

6.2.2 Different scenarios regarding transport of multiple segments 

6.2.2.1 Finding the segment lists 

When using an entry point address in pull mode, the HTTP request always sends back the complete service discovery 
record without segmentation. This can be the complete set for all service providers (request with "id=ALL") or a 
specific service provider record ("id=<doinain name of the service provider>"). 

When receiving SD&S information from multicast address(es), the DVBSTP header has a payload ID field and a 
segment ID field on each packet. These fields allow to capture the list of segments for each payload type by listening to 
a complete carrousel cycle time. 

Additionally service provider records may list the segments that are made available through each announced source 
(either push or pull). This list is mandatory for pull sources since there is no other way (see note) in this case to get the 
list. It may be provided for push mode since this allows the HNED to know if it has acquired everything without 
necessarily waiting for the maximum cycle time. 

NOTE: Actually there is a way: send a request to get each possible segment number and see which succeed or 
fail. But this is not practically feasible with 65 536 possible segment IDs. 

6.2.2.2 Filtering service providers in DVBSTP 

The DVB-IPTV handbook allows the case where several Service Providers use independent equipments to serve their 
own SD&S data. It is then possible that several service providers use the same multicast group to send DVBSTP 
packets containing the descriptions of their offer (Service Provider Discovery records). Then because the service 
providers are not centrally coordinated, they might well choose segment IDs that are the same. 

The DVBSTP has a ServiceProviderlD field, mandatory in this kind of configuration, that is used to signal the 
service provider identity (in the form of an IP address unique to the service provider). This allows the HNED to sort the 
received information and build a correct hst of segments assigned by each service provider. See TS 102 034 [1], 
clause 5.4.1.3.3. 

6.3 Acquisition of Live Channels Services 

The acquisition of Live Channels services is performed through the retrieval of the content of the "Package" and 
"Broadcast" files. 

NOTE: Live Channels can also be retrieved thanks to the BCG; this is presented in the BCG clause of the present 
document. 

If there is a Package service, the HNED can collect (via Push or Pull mode) the "service names" of the channels 
composing its bouquet. 

Then, the HNED can access (via Push or Pull mode) the XML file that contains the BroadcastDiscovery structure. 
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For the Broadcast Discovery Information Record, there are two modes: 

• "TS Full SI" (SD&S + DVB-SI): 

It provides only the necessary SD&S information to find available live media broadcast services which have 
embedded SI. Information on individual services is afterwards acquired from the transport stream itself 
through classical use of service information as defined in DVB-SI. As even the service name is not provided in 
SD&S, the HNED needs to connect to all services and parse all SI to build the service list. 

• "TS Optional SI" (only SD&S): 

It provides all the necessary SD&S information to create a list of available services with sufficient information 
for the user to make a choice and gives the necessary information on how to access the service. 

In the following part, we consider the "TS Optional SI" mode. 



6.4 Complete SD&S example 

This clause presents a workable example of SD&S discovery, and shows all different DVB-IPTV technologies that can 
be used (packages, FEC, regionalization, media transport). 

6.4.1 Service Provider Discovery Record 

As an example, the Service Provider discovery record below contains 2 service providers: "Providerl" and "Provider2". 
Each provider proposes 2 services: a Package service (Payload ID value=5) and a Broadcast service (Payload ID 
value=2). 





Providerl 


Provider2 


Services 


Package 
(Payload ID value=5) 


Package 
(Payload ID value=5) 


Broadcast 
(Payload IDvalue=2) 


Broadcast 
(Payload ID value=2) 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 
xmlns :xsi="http : //www.w3 . org/2 01/XMLSchema- instance" > 
<ServiceProviderDiscovery> 

<ServiceProvider DomainName= "providerl . com" LogoURI="0" Version=" 0" > 
<Name Language="ENG" >Providerl</Name> 

<Description Language="ENG" >Providerl ADSL TV Of f er</Description> 
<0f f ering> 

<Push Address="224 .1.1.5" Port="1234" Source=" 192 . 100 . 100 . 70 " > 
<PayloadId Id="5"> 

<Segment ID="1" Version="2"/> 
</PayloadId> 
</Push> 
</0f f ering> 
<0f f ering> 

<Push Address="224 .1.1.2" Port="1234" Source=" 192 . 100 . 100 . 70 " > 
<PayloadId Id="2"> 

<Segment ID="3" Version="2"/> 
</PayloadId> 
</Push> 
</0f f ering> 
</ServiceProvider> 

<ServiceProvider DomainName="provider2 . com" LogoURI="0" Version="0"> 
<Name Language="ENG" >Provider2</Name> 

<Description Language="ENG" >Provider2 ADSL TV Of f er</Description> 
<0f f ering> 

<Push Address="224 .1.1.6" Port="1234" Source=" 192 . 100 . 100 . 75 " > 
<PayloadId Id="5"> 

<Segment ID="0" Version=" 0"/> 
</PayloadId> 
</Push> 
</0f f ering> 
<0f f ering> 

<Push Address=" 224 .1.1.3" Port="1234" Source="192 . 100 . 100 . 75" > 
<PayloadId Id="2"> 

<Segment ID="2" Version="3"/> 
</PayloadId> 
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</Push> 
</0f f ering> 
</ServiceProvider> 
</ServiceProviderDiscovery> 
</ServiceDiscovery> 



6.4.2 Package and Broadcast Discovery with Regionalization 

As an example, the "Package" file below corresponds to the "Providerl". For this service provider, 2 bouquets are 
proposed: "Providerl Bouquetl" and "Providerl Bouquet2". The bouquet "Providerl Bouquetl" contains the channels 
"Channel 2", "Channel 3" and "Channel 5". The bouquet "Providerl Bouquet2" contains the channels "Channel 7", 
"Channel 8" and "Channel 9". The provider uses UDP streaming. 

Furthermore, the service provider assigns Logical Channel Numbers (LCN) to services described in the SD&S records, 
as presented in the following table, and also provides availability information. 





Providerl Bouquetl 


Providerl Bouquet2 | 


Channels 


Channel2 


LCN = 1 


Channel 7 


LCN = 2 


Channels 


LCN = 3 


Channel 8 


LCN = 4 


Channels 


LCN = 6 


Channel 9 


LCN = 5 



<?xml version="l . 0" encoding="UTF-8" ?> 






<ServiceDiscovery xmlns="urn:dvb imetadata : iptv: sdns : 2008-1" | 


xmlns :xsi="http: //www.w3 . org/2 01/XMLE 


chema-instance" > 


<PackageDiscovery DomainName= "providerl . com' 


Version="0" > 


<Package Id="l"> 






<PackageName Language="ENG 


>Providerl Bouquet l</PackageName> | 


<Service> 






<TextualID ServiceName= 


"Channel2 


/> 


<LogicalChannelNumber=' 


l"/> 




</Service> 






<Service> 






<TextualID ServiceName= 


"Channels 


/> 


<LogicalChannelNumber=' 


3"/> 




</Service> 






<Service> 






<TextualID ServiceName= 


"Channels 


/> 


<LogicalChannelNumber= ' 


6"/> 




</Service> 






<PackageAvailability> 






< Country Code Availabili 


ty="true">UK</CountryCode> | 


<Cell>Scotland</Cell> 






<Cell>Ireland</Cell> 






</PackageAvailability> 






</ Package > 






< Package Id="2"> 






<PackageName Language="ENG 


>Providerl Bouquet2</PackageName> | 


<Service> 






<TextualID ServiceName= 


"Channel? 


/> 


<LogicalChannelNumber=' 


2"/> 




</Service> 






<Service> 






<TextualID ServiceName= 


"Channels 


/> 


<LogicalChannelNumber= ' 


4"/> 




</Service> 






<Service> 






<TextualID ServiceName= 


"Channels 


/> 


<LogicalChannelNumber=' 


5"/> 




</Service> 






<PackageAvailability> 






< Count ryCode Availabili 


ty=" false 


>UK< / Count ryCode > 


<Cell>Scotland</Cell> 






<Cell>Wales</Cell> 






</PackageAvailability> 






</Package> 






</PackageDiscovery> 






</ServiceDiscovery> 
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As an example, the "Broadcast" file below corresponds to the "Providerl". We retrieve in the broadcast discovery 
record the ServiceName from the package discovery record. The package record provides the logical channel number, 
while the broadcast record provides the complete information on the service. 





Providerl 


Channels 


Channel 2 


Channel 3 


Channel 5 


Channel 7 


Channel 8 


Channel 9 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 

xmlns :xsi="http : //www. w3 . org/2 01/XMLSchema- instance" > 

<BroadcastDiscovery DomainName= "providerl . com" Version="0"> 
<ServiceList> 

< Service sDe script ionLocation> 

<DescriptionLocation>bcgl</DescriptionLocation> 

<DescriptionLocation pref erred="true">bcg2</DescriptionLocation> 
< /Service sDe script ionLocation> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . Ill . 1 . 12" Port="8208" Source="192 . 100 . 100 . 50" 
Streaming="udp" /> 
</ServiceLocation> 

<TextualIdentif ier DomainName= "providerl . com" ServiceName="Channel2"/> 
<DVBTriplet OrigNetId=" " Serviceld="5002" TSId="202"/> 
<MaxBitrate>4000</MaxBitrate> 
<ServiceAvailability> 

< Count ryCode Ava i 1 ab i 1 i ty= " t rue " >UK< / Count ryCode > 
<Cell>Scotland</Cell> 
<Cell>Ireland</Cell> 

</ServiceAvailability> 
<ServiceAvailability> 

<CountryCode Availability="true" >FR</CountryCode> 
</ServiceAvailability> 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . Ill . 1 . 13" Port="8208" Source="192 . 100 . 100 . 50" 
Streaming="udp" /> 
</ServiceLocation> 

<TextualIdentif ier DomainName= "providerl . com" ServiceName="Channel3"/> 
<DVBTriplet OrigNetId="0 " Serviceld="5003" TSId="203"/> 
<MaxBitrate>40 0</MaxBitrate> 
<ServiceAvailability> 

< Count ryCode Ava i 1 ab i 1 i ty= " t rue " >UK< / Count ryCode > 
<Cell>Scotland</Cell> 
<Cell>Ireland</Cell> 

</ServiceAvailability> 
<ServiceAvailability> 

<CountryCode Availability="true" >FR</CountryCode> 
</ServiceAvailability> 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . Ill . 1 . 15" Port="8208" Source="192 . 100 . 100 . 50" 
Streaming="udp" /> 
</ServiceLocation> 

<TextualIdentif ier DomainName= "providerl . com" ServiceName="Channel5"/> 
<DVBTriplet OrigNetId=" " Serviceld="5aa5" TSId="205"/> 
<MaxBitrate>4000</MaxBitrate> 
<ServiceAvailability> 

< Count ryCode Ava i 1 ab i 1 i ty= " t rue " >UK< / Count ryCode > 
<Cell>Scotland</Cell> 
<Cell>Ireland</Cell> 

</ServiceAvailability> 
<ServiceAvailability> 

<CountryCode Availability="true" >FR</CountryCode> 
</ServiceAvailability> 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . Ill . 1 . 27" Port="8208" Source="192 . 100 . 100 . 50" 
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Source="192 . 100 . 100 . 50" 



Streaming="udp" /> 
</ServiceLocation> 

<TextualIdentif ier DomainName="providerl . com" ServiceName="Channel7"/> 
<DVBTriplet OrigNetId=" " Serviceld=" 5007" TSId="207"/> 
<MaxBitrate>4000</MaxBitrate> 
<ServiceAvailability> 

< Count ryCode Ava ilability=" false" >UK< / Count ryCode > 
<Cell>Scotland</Cell> 
<Cell>Wales</Cell> 
</ServiceAvailability> 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . Ill . 1 . 28" Port="820 
Streaming="udp" /> 
</ServiceLocation> 

<TextualIdentif ier DomainName="providerl . com" ServiceName="Channel8"/> 
<DVBTriplet OrigNetId=" " Serviceld="5008" TSId="208"/> 
<MaxBitrate>4000</MaxBitrate> 
<ServiceAvailability> 

< Count ryCode Availability=" false" >UK< /Count ryCode > 
<Cell>Scotland</Cell> 
<Cell>Wales</Cell> 
</ServiceAvailability> 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . Ill . 1 . 29" Port="820 
Streaming="udp" /> 
</ServiceLocation> 

<TextualIdentif ier DomainName="providerl . com" ServiceName=" Channels"/ 
<DVBTriplet OrigNetId=" " Serviceld=" 5009" TSId="209"/> 
<MaxBitrate>4000</MaxBitrate> 
<ServiceAvailability> 

< Count ryCode Aval lability=" false" >UK</ Count ryCode > 
<Cell>Scotland</Cell> 
<Cell>Wales</Cell> 
</ServiceAvailability> 
</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 



Source="192 . 100 . 100 . 50" 



NOTE: The Service Availability in the broadcast record matches the Package Availability in the package record, 
but can also contain more parameters, as shown with the first package and the first 3 services defined 
there. 

6.4.3 Package and Broadcast Discovery with Error Recovery 

As an example, the "Package" file below corresponds to the "Provider2". For this service provider, only one bouquet is 
proposed: "Provider2 Bouquet". The bouquet "Provider2 Bouquet" contains the channels "Channel 15", "Channel 16", 
"Channel 17" and "Channel 18". The provider uses RTP streaming and provides FEC protection for channels 15 (only 
base layer) and channel 16 (base and enhancement layers), and RET protection for channels 17 and 18. 





Provider2 Bouquet 


Channels 


Channel 15 


Channel 16 


Channel 17 


Channel 18 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 

xmlns :xsi="http : //www.w3 . org/2 01/XMLSchema- instance" > 

<PackageDiscovery DomainName="provider2 . com" Version="0"> 
< Package Id="3"> 

<PackageName Language="ENG" >Provider2 Bouquet </PackageName> 
<Service> 

<TextualID ServiceName=" Channel 15"/> 
</Service> 
<Service> 

<TextualID ServiceName=" Channel 16"/> 
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</Service> 
<Service> 

<TextualID ServiceName=" Channel n"/> 
</Service> 
<Service> 

<TextualID ServiceName=" Channel 18"/> 
</Service> 
</Package> 
</PackageDiscovery> 
</ServiceDiscovery> 



As an example, the "Broadcast" file below corresponds to the "Provider2". 





Provider2 


Channels 


Channel 15 


Channel 16 


Channel 17 


Channel 18 



Port="8208" Source="192 .100. 100. 20" 
FECMaxBlockSizeTime="100"> 
"8210" Source="192 .100. 100. 20" 
/> 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 

xmlns :xsi="http : //www.w3 . org/2 01/XMLSchema- instance" > 

<BroadcastDiscovery DomainName="provider2 . com" Version="0" 
<ServiceList> 

<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 .222 .2 . 15" 

Streaming="rtp" FECMaxBlockSizePackets="8" 
<FECBaseLayer Address="224 . 222 . 2 . 15" Port= 
PayloadTypeNumber= "96" MaxBi trate= "300" 
</IPMulticastAddress> 
</ServiceLocation> 

<TextualIdentif ier DomainName="provider2 . com" ServiceName=" Channel 15"/> 
<DVBTriplet OrigNetId="0 " Serviceld="6001" TSId="5"/> 
<MaxBitrate>4 0</MaxBitrate> 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . 222 . 2 . 16" Port="8208" Source="192 . 100 . 100 . 20" 
Streaming="rtp" FECMaxBlockSizePackets="8" FECMaxBlockSizeTime="10 0" 
FECOTI = "MDB j MTA1MDE= " > 

<FECBaseLayer Address="224 .222 .2 .16" Port="8210" Source=" 192 . 100 . 100 . 20 " /> 
<FECEnhancementLayer Address="224 . 222 . 3 . 16" Port="4304" 

Source="192 .100.100.20" MaxBitrate="2 00" PayloadTypeNumber="102 " 
TransportProtocol="RTP-AVP" /> 
</IPMulticastAddress> 
</ServiceLocation> 

<TextualIdentif ier DomainName="provider2 . com" ServiceName=" Channel 16"/> 
<DVBTriplet OrigNetId=" " Serviceld=" 6002 " TSId="6"/> 
<MaxBitrate>4 0</MaxBitrate> 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . 222 . 2 . 17" Port="8208" Source="192 . 100 . 100 . 20" 
Streaming="rtp" > 
<RTPRetransmission> 

<RTCPReporting DestinationAddress= 
</RTPRetransmission> 
</IPMulticastAddress> 
</ServiceLocation> 
<TextualIdentif ier DomainName="provider2 . com" ServiceName=" Channel 17"/; 



'192.100.100.9" DestinationPort="65" /> 



<DVBTriplet OrigNetId=" " Serviceld="6003" TSId="7"/> 
<MaxBitrate>4000</MaxBitrate> 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . 222 . 2 . 18" Port="8208" Source="192 . 100 . 100 . 20" 
Streaming="rtp" > 
<RTPRetransmission> 

<RTCPReporting DestinationAddress="192 . 100 . 100 . 8" DestinationPort="54" /> 
</RTPRetransmission> 
</lPMulticastAddress> 
</ServiceLocation> 
<TextualIdentif ier DomainName="provider2 . com" ServiceName=" Channel 18"/> 
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<DVBTriplet OrigNetId=" " Serviceld="6004" TSId="8'7= 
<MaxBitrate>4000</MaxBitrate> 
</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 



NOTE: FEC Base Layer is compliant to SMPTE 2022-1 [4], so it is strongly recommended that the Address 

field is identical to the Address field of the content itself and the Port field is +2 from the Port field 
of the content. Note that any other values will break compliance with SMPTE 2022-1 [4]. 

6.5 More Complex Examples for SD&S 

This clause intends to present SD&S examples dealing with all possibilities offered by the DVB-IPTV handbook. 

6.5.1 Service Provider Discovery 

6.5.1 .1 Service Provider Discovery with Redundant Push/Pull Locations 

The aim of the following record is to advertise a broadcast discovery record several times, pointing to different 
servers/multicast addresses. This allows the HNED to connect to different servers in case some of them are 
momentarily not responding. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 
xmlns :xsi="http : //www.w3 . org/2 1/XMLSchema- instance" > 
<ServiceProviderDiscovery> 

<ServiceProvider DomainName="providerl . com" LogoURI="0" Version=" 0" > 
<Name Language="ENG" >Providerl</Name> 

<Description Language="ENG" >Providerl ADSL TV Of f er</Description> 
// one same package offering announced several times 
<0f f ering> 

<Pull Location= "packages . provider 1 . com/dvb/sdns/" > 
<PayloadId Id="5"> 

<Segment ID="12cf" Version="2e"/> 
<Segment ID="3 0d2" Version="ac"/> 
<Segment ID="12" Version="2"/> 
</PayloadId> 
</Pull> 

<Pull Location= "packages .other location. provider 1 . com/dvb/sdns/" > 
<PayloadId Id="5"> 

<Segment ID="12cf" Version="2e"/> 
<Segment ID="30d2"/> 
<Segment ID="12"/> 
</PayloadId> 
</Pull> 
<Push Address="224 .1.1.5" Port="1234" Source=" 192 . 100 . 100 . 70 " > 

<PayloadId Id="5"/> 
</Push> 

<Push Address="224 .1.3 .5" Port="5678" Source=" 192 . 100 . 100 . 70 " > 
</Push> 

<Push Address="224 .1.7.5" Port="1234" Source=" 192 . 100 . 100 . 70 " > 
<PayloadId Id="5"/> 

<Segment ID="12cf" Version="2e"/> 
<Segment ID="30d2"/> 
<Segment ID="12"/> 
</PayloadId> 
</Push> 
</0f f ering> 
// one broadcast offering announced 
<0f f ering> 

<Push Address="224 .1.1.2" Port="1234" Source="192 . 100 . 100 . 70 " > 
<PayloadId Id="2"> 

<Segment ID="12cf" Version="2e"/> 
</PayloadId> 
</Push> 
</0f f ering> 
</ServiceProvider> 
</ServiceProviderDiscovery> 
</ServiceDiscovery> 
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In this example, the first offer is a package discovery record which is announced through 4 different possibiHties, 2 pull 
and 3 push. Note that: 



• 



for the pull mode, the location of the server is different, but segments are the same since the same content is 
available; 

• for the push mode, it is not mandated to announce segments; it is not even mandated to announce the payload 
id. In that case, the HNED will check when receiving the header of the DVBSTP packets. 

The second offer is a broadcast one; it has the same segment and version as the first offer, which is acceptable because 
we talk here about a different offer. 

NOTE: The Payload@ID attribute is expressed in the XML data structure in hexadecimal coded with 1 or 2 
characters, while it is coded with exactly 2 characters in the URL of the HTTP request. 
The Segment@ID attribute is expressed in the XML data structure in hexadecimal coded with 1 to 4 
characters, while it is coded with exactly 4 characters in the URL of the HTTP request. 
The Segment@Version attribute is expressed in the XML data structure in hexadecimal coded with 1 or 2 
characters, while it is coded with exactly 2 hexadecimal characters in the URL of the HTTP request. 
For example, for the first pull location: 

<Pull Location= "packages . provider 1 . com/dvb/sdns/"> 
<PayloadId Id="5"> 

<Segnient ID="12cf" Version="2e"/> 
<Segment ID="30d2" Version="ac"/> 
<Segment ID="12" Version="2 "/> 
</PayloadId> 
</Pull> 

the HTTP requests to retrieve the segments are: 

GET /dvb/sdns/service_discovery?id=providerl . com&Payload=05&Segment=12cf &Version=2e 
GET /dvb/sdns/service_discovery?id=providerl . com&Payload=05&Segment=30d2&Version=ac 
GET /dvb/sdns/service_discovery?id=providerl . comS;Payload=05S;Segment = 0012S;Version=02 

6.5.1 .2 Service Provider Discovery with Complementary Push/Pull Locations 

In the previous example we talked about redundancy for the announcement of the SD&S data. It consumes server 
resource and bandwidth resource to do that, while a service provider may want to optimize the resources to send the 
SD&S data. 

Let us base the following example on a broadcast offering by a service provider (other payload ids can of course be 
used). We assume a service provider has 200 TV channels. If no splitting at all was performed, the offering can be 
included in a unique segment sent on one multicast group. Assuming an average size of each single service XML record 
of 1 k-byte, we have 200 k-bytes to send in a maximum delay of 30 seconds. This produces a bitrate of 53 kbits/s in the 
SD&S multicast. 

At the opposite, we can build 200 segments, each one containing the description for only one service, and assign a 
different multicast group to the sending of each segment such as illustrated below. There is also the possibility to split 
the HTTP server load, here 2 servers are defined, to hold odd and even segment numbers (but any split is possible, with 
any number of servers). 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns=" urn :dvb: metadata : iptv: sdns : 2008-1" 
xmlns :xsi="http : //www.w3 . org/2 1/XMLSchema- instance" > 
<ServiceProviderDiscovery> 

<ServiceProvider DomainName="providerl . com" LogoURI="0" Version="0"> 
<Name Language="ENG" >Providerl</Name> 

<Description Language="ENG" >Providerl ADSL TV Of f er</Description> 
// one broadcast offering announced in several pieces 
<0f f ering> 

<Push Address="224 .1.7.0" Port="1234" Source=" 192 . 100 . 100 . 70 " > 

<PayloadId Id="2"/><Segment ID="0"/></PayloadId> 
</Push> 
<Push Address="224 .1.7.1" Port="1234" Source=" 192 . 100 . 100 . 70 " > 

<PayloadId Id="2"/><Segment ID="l"/></PayloadId> 
</Push> 
<Push Address="224 .1.7.2" Port="1234" Source=" 192 . 100 . 100 . 70 " > 

<PayloadId Id="2"/><Segment ID="2"/></PayloadId> 
</Push> 
[ ] 
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<Push Address="224.1.7.198" Port="1234" Source=" 192 . 100 . 100 . 70 " > 


<PayloadId Id="2"/><Segment ID="c6"/></PayloadId> 


</Push> 




<Push Address="224.1.7.199" Port="1234" Source=" 192 . 100 . 100 . 70 " > 


<PayloadId Id="2"/><Segment ID="c7"/></PayloadId> 


</Push> 




<Pull Location=" 


services Oto9 9 . provider 1 . com/dvb/sdns/" > 


<PayloadId Id="2"> | 


< Segment 


ID="0"/> 


< Segment 


ID="2"/> 


<Segment 
[ 


ID="4"/> 
] 


<Segment 


ID="c4"/> 


<Segment 


ID="c6"/> 


</PayloadId> 




</Pull> 




<Pull Location=" 


servicesl0 0tol99 . provider 1 . com/dvb/sdns/" > 


<PayloadId Id="2"> | 


<Segment 


ID="l"/> 


<Segment 


ID="3"/> 


<Segment 
[ 


ID="5"/> 
] 


< Segment 


ID="c5"/> 


< Segment 


ID="c7"/> 


</PayloadId> 




</Pull> 




</0f f ering> 




</ServiceProvider> 




</ServiceProviderDiscovery> 




</ServiceDiscovery> 





Sending each multicast stream with a cycle time of 30 seconds makes a bitrate of only 266 bits/s for each. So the HNED 
which wants to check only a few channel descriptions generates a bandwidth of only a few times these 266 bits/s. 

If the HNED wants to monitor everything simultaneously, it will join all the multicast groups and receive a total bitrate 
of 52 kbits/s - the same as if only one stream was used. This can be used for example at boot time to acquire the 
complete service plan. Since each stream cycles in 30 seconds, the HNED still receives the complete information in 
30 seconds. 

Then since SD&S updates are not frequent, the HNED might decide to listen to only one multicast group at a time. This 
uses a permanent bandwidth of only 266 bits/s. Each segment is received in (maximum) 30 seconds. So at most after 
30 seconds, the HNED leaves the current group and joins the next one. The total time to scan all the information is now 
(maximum) 1 hour and 40 minutes. 

Between the 2 extreme options - all in one segment and one service per segment with one stream per segment - the 
service provider has much flexibility to find a good compromise between the use of bandwidth, the time it takes to 
check updates and the number of multicast addresses used (which may be limited). 

6.5.1 .3 Simplest Service Provider Discovery Offer 

Since the Payload element is not required for push location, the following XML table is the simplest possible one for 
service provider discovery. Of course the only way for the HNED to know what is offered is to join the multicast 
groups and check the payload id within the DVBSTP headers. Note that the Source field of the Push element is 
optional, it was not set here. 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 
xmlns :xsi="http : //www.w3 . org/2 01/XMLSchema- instance" > 
<ServiceProviderDiscovery> 

<ServiceProvider DomainName="providerl . com" LogoURI="0" Version=" 0" > 
<Name Language="ENG" >Providerl</Name> 

<Description Language="ENG" >Providerl ADSL TV Of f er</Description> 
<0f f ering> 

<Push Address="224 . 1 . 1 . 5" Port="1234" /> 
</0f f ering> 
<0f f ering> 

<Push Address="224 .1.1.2" Port="1234" /> 
</0f f ering> 
</ServiceProvider> 
</ServiceProviderDiscovery> 
</ServiceDiscovery> 
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6.5.2 Broadcast Offering with Multiple Multicast/RTSP Locations 

It is also possible to provide several locations that allow access to the content. The following example presents a 
complex example with several push and pull locations. There are 2 RTSP servers able to provide session management 
for this live content, one multicast stream using UDP streaming without FEC, and one multicast stream using RTP with 
FEC. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 

xmlns :xsi="http : //www.w3 . org/2 01/XMLSchema- instance" > 

<BroadcastDiscovery DomainName="providerl . com" Version="0"> 
<ServiceList> 

<SingleService> 

<ServiceLocation> 

<RTSPURL>rtsp: //live .providerl . com/Channel2 .mpg</RTSPURL> 

<IPMulticastAddress Address="224 . Ill . 1 . 12" Port="8208" Source="192 . 100 . 100 . 50" 

Streaming="udp" /> 
<IPMulticastAddress Address="224 . Ill . 1 . 22" Port="4302" 

Streaming="rtp" FECMaxBlockSizePackets="8" FECMaxBlockSizeTime="100" > 
<FECBaseLayer Address="224 .111.1.22 Port="4304" Source=" 192 . 100 . 100 . 50 " /> 
</IPMulticastAddress> 

<RTSPURL>rtsp : //live .proxy .providerl . com/Channel2 .mpg</RTSPURL> 
</ServiceLocation> 

<TextualIdentif ier DomainName= "providerl . com" ServiceName="Channel2"/> 
<DVBTriplet OrigNetId="0 " Serviceld="5002" TSId="202"/> 
<MaxBitrate>4000</MaxBitrate> 
</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 

NOTE: The order of service locations is not important, therefore there is no preference or default location 
implied. 



6.5.3 Single Big Push Discovery 



Since DVBSTP has all information in the header of the packet to discriminate payload ids and segments, it is possible 
for a service provider to provide all the SD&S data on one single multicast address. The following XML tables are an 
example of such a system. 

The entry point provides the multicast address 224. 1.1.1 to discover the Service Provider Discovery record. This record 
is as follows: 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 
xmlns :xsi="http : //www.wS .org/2 01/XMLSchema- instance" > 
<ServiceProviderDiscovery> 

<ServiceProvider DomainName= "providerl . com" LogoURI="0" Version=" 0" > 
<Name Language="ENG" >Providerl</Name> 

<Description Language="ENG" >Providerl ADSL TV Of f er</Description> 
<0f f ering> 

<Push Address="224 .1.1.1" Port="1234" /> 
</0f f ering> 
<0f f ering> 

<Push Address="224 .1.1.1" Port="1234" /> 
</0f f ering> 
</ServiceProvider> 
</ServiceProviderDiscovery> 
</ServiceDiscovery> 

Let us say that the first offering is a package record, and the second one is a broadcast record. 

The multicast group 224.1.1.1 is carrying three different payload ids data: the service provider discovery record (1), the 
broadcast record (2) and the package record (5). Each payload id can have several segments. 

The HNED will perform the parsing of payload ids and segment thanks to the DVBSTP header. 
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6.5.4 Multiple Coding Formats 



The SD&S data structure can provide audio and video formats used by the service. When a service provider is able to 
present the same service using several different formats (size, coding, etc.), it has to advertise several services in the 
service list. 

The following example shows the case of one service being available in SD and HD formats. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 

xmlns :xsi="http : //www. w3 . org/2 01/XMLSchema- instance" > 

<BroadcastDiscovery DomainName="providerl . com" Version="0"> 
<ServiceList> 

<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . Ill . 1 . 12" Port="8208" Source="192 . 100 . 100 . 50" 
Streaming="udp" /> 
</ServiceLocation> 

<TextualIdentif ier DomainName="providerl . com" ServiceName=" Channel -1 SD"/> 
<DVBTriplet OrigNetId=" " Serviceld="5002" TSId="202"/> 
<MaxBitrate>4000</MaxBitrate> 
<SI ServiceType="01" PrimarySISource="XML" > 

<Name Language="ENG" >Channel 1 - SD</Name> 
<Name Language="FRA" >Canal 1 - SD</Name> 

<Description Language="ENG" >This is the channel 1 in SD</Description> 
<Description Language="FRA" >Ceci est le canal 1 en SD</Description> 
</SI> 
<AudioAttributes> 

< Coding href =" urn: mpegimpegV : cs :AudioCodingFormatCS :2001:3.2"> 

<Name>MPEG-l Audio Layer II</Name> 
</Coding> 

<NumOf Channel s>2</NumOf Channel s> 
</AudioAttributes> 
<VideoAttributes> 

< Coding href =" urn: mpegimpegV : cs : VisualCodingFormatCS :2001:2.2.2"> 

<Name>MPEG-2 Video Main Profile ® Main Level</Name> 
</Coding> 
</VideoAttributes> 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . Ill . 1 . 13" Port="8208" Source="192 . 100 . 100 . 50" 
Streaming="udp" /> 
</ServiceLocation> 

<TextualIdentif ier DomainName="providerl . com" ServiceName=" Channel -1 HD"/> 
<DVBTriplet OrigNetId=" " Serviceld="5002" TSId="203"/> 
<MaxBitrate>10000</MaxBitrate> 
<SI ServiceType="19" PrimarySISource="XML" > 

<Name Language="ENG" >Channel 1 - HD</Name> 
<Name Language="FRA" >Canal 1 - HD</Name> 

<Description Language="ENG" >This is the channel 1 in HD</Description> 
<Description Language="FRA" >Ceci est le canal 1 en HD</Description> 
</SI> 
<AudioAttributes> 

<Coding href =" urn: dvb : metadata : cs :AudioCodecCS :2007:1.2.2"> 

<Name>MPEG-4 High Efficency Advanced Audio Profile @ Level 2</Name> 
</Coding> 

<NumOf Channe 1 s >2 < /NumOf Channe 1 s > 
</AudioAttributes> 
<VideoAttributes> 

<Coding href =" urn: dvb: metadata : cs : VideoCodecCS : 2007 : 1 . 4 . 12" > 

<Name>H264 High Profile @ Level 4.0</Name> 
</Coding> 
< /VideoAttributes > 
</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 
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6.6 Regionalization and Logical Channel Numbers (LCN) 

A HNED has used the SD&S mechanism to discover the available service providers and services in the IPTV network. 
The service provider assigns Logical Channel Numbers (LCN) to services described in the SD&S records. The LCN 
defines the service provider's preferred ordering of the available services in the HNED channel list. The LCN is a 
number associated with every service, allowing the presentation of the service and its selection. 

In this example all regional Channel2 services are listed contiguously, but they all use the same channel number since 
they are not supposed to exist simultaneously. 



LCN 


Channel 


Regional Availability 
(Cell 1) 


Regional Availability 
(Cell 2) 


1 


Channel2 regioni 


true 


false 


1 


Channel2 region2 


false 


true 


1 


Channel2 regions 


false 


false 


1 


Channel2 region4 


false 


false 


2 


Channels 


true 


true 


3 


Channels 


true 


true 



In Cell 1: 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb imetadataipi : : iptv: sdns :2006:2008-l" 

xmlns :xsi="http : //www.w3 . org/2 01/XMLSchema- instance" > 

<PackageDiscovery DomainName="providerl . com" Version="0" > 
<Package Id="l"> 

<PackageName Language="ENG" >Providerl Bouquet l</PackageName> 
<Service> 

<TextualID ServiceName="Channel2 regioni" /> 
<LogicalChannelNuiiiber=l/> 
</Service> 
<Service> 

<TextualID ServiceName="Channel3"/> 
<LogicalChannelNumber=2/> 
</Service> 
<Service> 

<TextualID ServiceName= "Channels "/> 
<LogicalChannelNuiiiber=3/> 
</Service> 
</Package> 
</PackageDiscovery> 
</ServiceDiscovery> 



In Cell 2: 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb imetadataipi : : iptv: sdns :2006:2008-l" 

xmlns :xsi="http : //www.wS .org/2 01/XMLSchema- instance" > 

<PackageDiscovery DomainName="providerl . com" Version="0" > 
<Package Id="l"> 

<PackageName Language="ENG" >Providerl Bouquet l</PackageName> 
<Service> 

<TextualID ServiceName="Channel2 region2"/> 
<LogicalChannelNumber=l/> 
</Service> 
<Service> 

<TextualID ServiceName="Channel3"/> 
<LogicalChannelNumber=2/> 
</Service> 
<Service> 

<TextualID ServiceName=" Channels "/> 
<LogicalChannelNumber=3/> 
</Service> 
</ Package > 
</PackageDiscovery> 
</ServiceDiscovery> 
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6.7 RMS-FUS Announcement Discovery 

A Service Provider may use an SD&S record carried over DVBSTP transport and identified by PayloadID = 0x08 to 
deliver information about the firmware update server (FUS) and the remote management service. 

For any RMS-FUS SD&S record the segmentid must have a value other than "0". In order to compact the payload for 
these messages during carriage GZIP may be used. 

There may be a single RMS-FUS SD&S record leading to an appropriate entry point in the FUS multicast 
announcement structure or multiple RMS-FUS SD&S records carrying information for different CPEs. Further 
navigation may be necessary within the FUS multicast announcement structure. 

The detailed description of how the information carried using this method of dehvery can be used to used is contained 
in TS 102 824 [3] and in Part 4 of this multi-part dehverable [i.8]. 

The description of the FUS may include: 

• its identity; 

• the multicast and unicast addresses of the announcement services; 

• the query/response channel (QRC) supported by that FUS. 

The RMS may be described in terms of its identity and the URJ of the management channel (interface 9 of the 
RMS-FUS logical architecture shown in TS 102 824 [3]. 

Some examples based on the schema described in TS 102 034 [1] are given below. 

In this example an FUS named "Echostar_FUS_3" is identified offering connection information using multicast to the 
announcement service, carried over DVBSTP, and the location of the QRC for that FUS. This record is intended to 
support an unmanaged CPE so no RMS is described. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 
xmlns :xsi="http : //www.w3 . org/2 01/XMLSchema- instance "> 
<RMSFUSDiscovery Version="0"> 

<FUSProvider LogoURI=" http : //lO . 1 . 1 . 34/LogoFUS . jpg "> 
<FUSName Language= " ENG" >Echostar_FUS_3 < /FUSName > 
<FUSID>12 34</FUSID> 

<Description Language="ENG" >FUS for EchoStar IPTV</Description> 
<FUSAnnouncement> 

<FUSAnnouncementDescription> 

Update to add improved menu features 
</FUSAnnouncementDe script ion> 
<iyiulticastAnnouncementAddress Address = "224 . 122 .2 .23" Port = "4321" 

Protocol="2 DVBSTP" /> 
<QRCLocation> http: //example. fus .dvb.org: 8 08 0/QRC </QRCLocation> 

< FUSUni c a s t Announc ement > http : //example . fus . dvb . org/UCFUS < / FUSUni c a s t Announc ement > 
< / FUSAnnouncement > 
</FUSProvider> 
</RMSFUSDiscovery> 
</ServiceDiscovery> 

In this example the multicast address provided must lead into the announcement system at a level only for CPEs 
covered by the description at the entry point identified, e.g. in the example the announcements should only describe 
firmware updates for CPEs maintained by the FUS. Also further navigation through the announcement system may be 
needed to identify the actual firmware update for the CPE. 

The provision of the QRC location allows the CPE to provide sufficient information over the unicast channel to the FUS 
for the FUS to provide the location information for the available firmware updates, but this can only be done based on 
comparisons of the information provided by the CPE with the metadata provided by the manufacturer. A more complete 
description of the use of the QRC is given in Part 4 of this present document. 

In the next example the record describes an RMS("Echo rms eui"), no FUS information is required because that is 
managed through the RMS, with the connection being made over the management channel. It is assumed that the CPE 
will contact the RMS which will provide the information to acquire the firmware update file to the CPE. 
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<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 
xmlns :xsi="http : //www.w3 . org/2 01/XMLSchema- instance" > 
<RMSFUSDiscovery Version="5"> 

<RMSProvider RMSLocation=" http : //example . rms .dvb.org: 7547 "> 
<RMSName Language="ENG" >Echo_RMS_EUl</RMSName> 
<RMSID>12 34</RMSID> 

<Description Language="ENG" >RMS serving EchoStar IPTV</Description> 
</RMSProvider> 
</RMSFUSDiscovery> 
</ServiceDiscovery> 

Both FUS and RMS information can be provided if desired, as in the example below. Note that the FUS and RMS are 
identified as different entities implying that they are physically separated as shown in the RMS-FUS architecture but 
they could be co-located in the same device. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 
xmlns :xsi="http : //www.w3 .org/2 001/XMLSchema- instance" > 
<RMSFUSDiscovery Version="0"> 

<FUSProvider LogoURI=" http : //lO . 1 . 1 . 34/LogoFUS . jpg " > 
<FUSName Language="ENG" >Echostar_FUS_3</FUSName> 
<FUSID>1234</FUSID> 

<Description Language="ENG" >FUS for EchoStar IPTV</Description> 
<FUSAnnouncement> 

<FUSAnnouncementDescription> 

Update to add improved menu features 
</FUSAnnouncementDescription> 
<iyiulticastAnnouncementAddress Address = "224 . 122 .2 .23" Port = "4321" 

Protocol="2 DVBSTP"/> 
<QRCLocation> http: //example. fus .dvb.org: 808 0/QRC </QRCLocation> 

<FUSUnicastAnnouncement> http : //example . f us . dvb . org/UCFUS </FUSUnicastAnnouncement> 
< / FUSAnnouncement > 
</FUSProvider> 

<RMSProvider RMSLocation=" http : //example . rms .dvb .org: 7547 " > 
<RMSName Language="ENG" >Echo_RMS_EUl</RMSName> 
<RMSID>1234</RMSID> 

<Description Language="ENG" >RMS serving EchoStar IPTV</Description> 
</RMSProvider> 
</RMSFUSDiscovery> 
</ServiceDiscovery> 



6.8 Versioning and Update Signalling 

TS 102 034 [1], clause 5.4.3 contains information on signalling changes in SD&S. The subsequent clause provides 
additional guidance and examples. 

6.8.1 Location of Version Information 

There are several locations where version numbers are provided in the SD&S mechanism. The list is numbered to 
reference the locations in the text afterwards. 

1) A Version attribute is present at the root level of the ServiceDiscovery XML element ([1], 
clause C.1.5). 

2) A Version attribute is present in the Of f eringBase XML element ([1], clause C. 1.4.24). This 
Of f eringBase element is inherited by all Discovery records (Broadcast record, BCG record . . .). 

3) A Version attribute is present at the ServiceProvider level in the Service Provider Discovery record 
(ServiceProviderType XML element, [1], clause C.1.3.39) and at the BCG level in the BCG Discovery 
record (BCGOf f ering XML element, [1], clause 1.4.1). 

4) A Version attribute is present in the segment element used in the PayloadList ([1], clause C. 1.3. 29) of 
a Service Provider discovery record and BCG discovery record. 

5) A Segment_Version field is present in the header of the DVBSTP packet ([1], clause 5.4.1.1). 
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6.8.2 Example using the BCG Discovery Record 

To show all Versions fields, we will use here an example with a BCG Discovery record. This example is quite complex 
on purpose. The BCG Discovery record is presented since it is the only one that is able to carry all Versions fields. All 
other records miss one Version field: the Service Provider Discovery record carries (3) but not (2), all other Offering 
records carry (2) but not (3). 

In this example, we present at first the Service Provider Discovery record that points to the BCG Discovery record. For 
the latter, DVBSTP transport is assumed, and while all version fields are set, some are optional and may be missing in 
real deployments. They are provided here as an example with all possible version fields present, since the DVB-IPTV 
handbook [1] does not forbid putting those Version fields. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb imetadata : iptv: sdns : 2008-1" >'—~v 
xmlns :xsi= http : //www.w3 . org/2 01/XMLSchema- instance Version=t''5f " 1 1 
<ServiceProviderDiscovery> ^~^^ 

<ServiceProvider DomainName="providerl . com" LogoURI = "0" Version=( 
<Name Language="ENG" >Providerl</Name> 

<Description Language="ENG" >Providerl ADSL TV Of f er</Description> 
<0f f ering> 

<Push Address="224 .22 .23 .24" Port="1234" Source=" 67 . 89 . 01 . 23 " > 
<PayloadId Id="6"> ^— ~^ 

<Segment ID="13" Version=(5d"^ 4 
</PayloadId> ^ — ^ 

</Push> 
</0f f ering> 
</ServiceProvider> 
</ServiceProviderDiscovery> 
</ServiceDiscovery> 

DVBSTP header 

|Ver |Resrv|Enc I C| Total_Segment_Size | 

+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - >"— Sv"*" 
I Payload ID= 6 | Segment ID = 13 | SegVersion/^5d J 5 

+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + ->>-»>> 
I Section_Number | Last Section Number | Compr | | HDR_LEN | 

XML Document (DVBSTP payload) 

<?xml version="l . 0" encoding="UTF-8" ?> 

<Serviceni:5wovery xmlns = "urn:dvb : ipisdns : 2006" xmlns :xsi= http : //www. w3 . org/2 01/XMLSchema- instance 

Version=r5d" d 1 ^^—^ 

<BCGEn?i!rer6very DomainName="pBe"»i^erl . com" Version=f 42" d 2 

<BCG Id="bcgl" Version=r'2a"^ 3 ^ 

<Name Language="eng"SJi*TOviderl BCG1</Name> 
<TransportMode > 

<HTTP Location="bcgl . provider 1 . com/dvb/sdns/" > 
<PayloadId Id="al"> ^""^v 

<Segment ID="7b" Versionf''4" A 4 
<Segment ID="4d5" Version^*Hr7"/> 
<Segment ID="1" Version="2"/> 
</PayloadId> 
<PayloadId Id="a2"> 

<Segment ID="0" Version="4"/> 
</PayloadId> 
</HTTP> 
</TransportMode> 

<TargetProvider>sport .providerl . com</TargetProvider> 
</BCG> 
<BCG Id="bcg2" Version="8"> 

<Name Language="eng" >Providerl BCG2</Name> 
<TransportMode > 

<DVBSTP Port="5512" Address="224 . 235 . 32 . 4 " > 
<PayloadId Id="al"> 

<Segment ID="7" Version="6"/> 
</DVBSTP> 
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< /TransportMode > 

<TargetProvider>news .providerl . com</TargetProvider> 
</BCG> 
</BCGDiscovery> ^'— ^ 

<BCGDiscovery DomainName="pBei^derl . com" Version=r'3" >1 2 
<BCG Id="bcg3" Version=r3" >) 3 ^^ — ^ 

<Name Language="eng"S*i*TOviderl BCG3</Name> 
<TransportMode > 

<HTTP Location="bcg3 .providerl . com/dvb/sdns/" > 
<PayloadId Id="al"> > — >^ 

<Segment ID="11" Version/"' 1" A 4 

</PayloadId> ^ 

</HTTP> 
< /TransportMode > 

<TargetProvider>movies .provider2 . com</TargetProvider> 
</BCG> 
</BCGDiscovery> 
</ServiceDiscovery> 



6.8.3 Carriage of version numbers 

Where the version numbers are carried depends on the transport protocol used to deliver the SD&S segments. The 
numbers in parenthesis refer to the numbered list above. 

• The version of a Service Provider (3) shall be always present. The version of a BCG (3) is optional in the 
DVB-IPTV handbook, but this Guidelines document strongly recommends that it is always present, in the 
same way the Service Provider one is. 

• If a segment is delivered using HTTP (pull mode): 

The version field at the root of the XML document (1) shall be present. 

When the record is an Offering record (based on the OfferingBase XML element), the version field of 
the OfferingBase (2) shall be present. 

• If a segment is delivered using DVBSTP (push mode), i.e. IP multicast: 

The version field is present in the DVBSTP header (5) of the segment. 

It is recommended that the version attributes (1) and (2) are not used. If it is present (1) shall be equal to 
(5). 

• The version number (4) of a Service Discovery information segment can optionally be signalled in the segment 
list that is contained in the ServiceProvider record, whether it is for HTTP or for DVBSTP. In the same way 
the version of a BCG container can be signalled via the BCG Discovery record. 

• As a BCG container does not contain its version number the version field it is strongly recommended that (4) 
is present for HTTP signalling of BCG containers. 

6.8.4 Update Detection 

The update of a SD&S record is signalled using the version numbers. The update mechanism can be summarized by the 
following logic: 

• Any change in an SD&S XML element increases the version of the corresponding record: 

this change will increase the Version attribute of the ServiceProvider or BCG level (3); 

this change will increase the Version attribute of the XML record (2) when this field is present 

(e.g. ServiceDicsovery .Broad.castDiscovery@Version for BroadcastDiscovery records). 

• Consequently, this change will also increase the Version attribute of the root level of the record (1), when 
this field is present (i.e. the ServiceDiscoveryOVersion) ; 
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• Consequently, this change will also increase the Segment_Version field of the DVBSTP packet header (5) 
when the record is transported in push mode. It will also increase the Version field of the PayloadList 
XML element (4), when this field is present. 

• Consequently, if this change is within an offering record (not the ServiceProviderDi scovery record), 
it means that the offering has changed, and this has to be reflected in the ServiceProviderDiscovery 
record where the offering records belongs to by increasing its version. Thus the 

ServiceProvider@Version (3) will be increased. This is done whether (4) is present or not, since the 
offering has changed; 

• Consequently, the Version attribute of the XML segment carrying the ServiceProviderDiscovery 

( 1 ) record will also be increased when this field is present (when delivered in pull mode). When sent in push 
mode, the Segment_Version field of the DVBSTP packet header (5) will be increased. 

As a summary, the following figures present the change chain of versioning. Changes are the squares in the records; 
arrows mean that the impact is to increase the version number pointed out by the arrow, in a sequential way. Different 
colours are used for different examples. The first figure is for the push mode via DVBSTP. 

Figure 6.1 presents an initial state of the records, with all version fields present. 



DVBSTP header 



I Ver I Resrv | Enc | C | 



Total_Segment_Size 



I Payload ID= 1 | Segment ID= |SegVersion= 9 | 

I SeGtion_Number | Last Section Number | Compr | | HDR_LEN | 



I Ver |Resrv|Enc | C | Total_Segment_Size | 

I Payload ID= 2 | Segment ID= 12cf | SegVersion^ 2 | 

I Section_Nuraber | Last Section Number | Compr | |HDR_LEN| 



ServiceProviderDiscovery record 



<ServiceDiscovery Version="9"> 
<ServiGeProviderDi scovery > 

<ServiceProvider Version="7"> 
<Name 

<Description 
<0f f ering> 
<Pull 

<PayloadId Id="2"> 

< Segment ID="12cf " Version="2 "/> 
<Segment ID="30d2" Version="3 "/> 
</PayloadId> 
</Pull> 
</0f f ering> 
< /Service Provider > 
</ ServiceProviderDiscovery > 
<ServiceProviderDi scovery > 

<ServiceProvider Version="2"> 
<Name 

<Description 
<0f f ering> 

<Push 
</0f f ering> 
< /Service Provider > 
</ ServiceProviderDiscovery > 
</ServiceDi scovery > 



<ServiceDi scovery > 

<BroadcastDi scovery Version="2" 
<ServiceList> 

<SingleService> 

<ServiceLocation> 

<RTSPURL 
</ServiceLocation> 
</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDi scovery > 



BroadcastOffering 

Record 

First segment 



Figure 6.1 : Initial state of the records with all version fields 



ETSI 



37 



ETSI TS 102 542-1 VI .3.2 (2011-05) 



When some changes occurred, those records become. 



DVBSTP header 

I Ver|Resrv|Enc|c| Total_Segment_Size 

I Payload ID^ 1 | Segment ID^ |SegVersion= 10 

H h- + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + 

I SeGtion_Number | Last Section Number | Comparf^ | HDR LEN| 

ServicePro viderDisco ven 




I Ver I Resrv | Enc | C | Total_Segment_Size | 

I Payload ID= 2 | Segment ID^ 12cf | SegVersion»- 3 | 

I Section_Number | Last Section Number JCtwrl^n 1 HDR_LEN| 



<ServiceDiscovery Version. 

<ServiceProviderDiscover^ 
<ServiceProvider Ver: 
-iMama 



change 



<Description 
im££airingr. 



< Segment 
</PayloadId> 
</Pull> 
</0f f ering> 
</ServiceProvider> 
</ServiceProviderDiEcovery> 
<ServiceProviderDiscovery> 

<'i''vioePi''ovid(M : Version^ "3 



change 




<Pull 

<PayloadId lb 

<Segment \lD="12cf " Version^" 



D^"30d2" Version^"3"/> 



<Name 



<0f f ering> 

<Push 
</0f f ering> 
</ Service Provider > 
< /Service ProviderDiEcovery> 
</ServiceDiscovery> 



<ServiceDiscovery: 

<BroadcastDiscovery Version^' 3 
<ServiceList 

<SingleSer; 

ffiooLooat 



</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiEcovery> 





BroadcastOffering 

Record 

First segment 



Figure 6.2: State of the records with all version fields after changes 

It is important to note that the DVB-IPTV handbook [1] does not provide any strict rule on the version increase 
mechanism itself. In the previous example, several changes occurred and though the version is only increased by one. 
This is a service provider choice whether the versions are increased at each change, or if the versions are increased by a 
group of changes, in which case the frequency of increase actions is also a service provider implementation choice. 

Figures 6.3 and 6.4 show the same records, but with only mandatory version fields. When delivered with DVBSTP. 



DVBSTP headers 



I Ver I Resrv | Enc | C | Total_Segment_Size | 

I Payload ID= 1 | Segment ID= |SegVersion= 10 | 

I Section_NurQber | Last Section Number | Compr | QnpHDR/LEN 



I Ver I Resrv I Enc | C | Total_Segment_Size 

Payload ID= 2 | Segment ID= 12ce | SegVersion= 3 

Section_Number | Last Section Number | Cqi])j>!rTO |HD5<"LEN| 



ServicePro viderDisco very record 




<ServiceDiscovery> 

<ServiceProviderDiscovery> 

<ServiceProvider Version="8 
<Name . . . 
<Description . . . 
<0f fering> 

<Pull . . . 

<PayloadId Id="2"> 

<Segment ID^"12cf 
<Segment ID="3 0d2 
</PayloadId> 
</Pull> 
</0f f ering> 
</ServiceProvider> 
</ServiceProviderDiscovery: 
<ServiceProviderDiscovery> 

<a ei- ' vi e ePra^ der Version^ 
I <Name 
*■ «>Dc!.LiijJ^ion 
<0f fering> 

<Push . . . 
</0f f ering> 
</ServiceProvider> 
</ServiceProviderDiscovery: 
</ServiceDiscovery> 



Figure 6.3: Records with only mandatory version fields with DVBSTP transport 
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And when HTTP is used, there is no DVBSTP header anymore. 



ServiceProviderDiscovery record 



BroadcastOffering Record 



<ServiceDiscovery Version="a"> 

<ServiceProviderDiscover^jir**N,C' "•" 
<ServiceProvider Vers4on= 
<Name 

<Description 
<0f f ering> 
<Pull 

<PayloadId lfe=" 

< Segment \lD="12cf " Version="3 " 
<Segment \:D="3 0d2" Version="3 "/> 
</PayloadId> 
</Pull> 
</0f f ering> 
</ServiceProvider> 
</ServiceProviderDiscovery> 
<ServiceProviderDiscovery> 

Version= 
cName 
uDescL" 
<0f f ering> 

<Push 
</0f f ering> 
</ServiceProvider> 
</ ServiceProviderDiscovery > 
</ServiceDiscovery> 




++ 



<ServiceDiscGvery> 

<BrGadcastDiscovery Vers ion 
<ServiceLis t_>^ 

ervice> 
piuiuHLuuaLiu 
<RTSPURL 
</^l dHJlLJ I dLUUaLi^ n> 
</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 



Figure 6.4: Records with only mandatory version fields with HTTP transport 



Connection to the Content 



At this step, the HNED has collected the XML files that contains the content description (SD&S or BCG structures). 
The HNED can then connect to the content. This will involve different mechanisms whether the content is live 
broadcast or on-demand. 



7.1 



Connection to Live Content 



Live content is typically described using SD&S metadata, but it can also be exposed using BCG metadata. 

7.1.1 Connection possibilities 

A Live TV service may be accessed by an individual HNED in the following ways; 

• Using Internet Group Management Protocol (IGMP): 

In this case, the HNED has collected a Multicast IP address for this Live TV service. To display this Live TV 
channel, the HNED sends an IGMP Report request to this Multicast IP address in order to subscribe to this 
multicast group. Multicast Content Services use IGMP version 3 with Source Specific Multicast. This allows 
significant scalability and implementers should note that the previous version of IGMP is not allowed (see 
clause 7.3 for details). 

• Using Real Time Streaming Protocol (RTSP): 

In this case, the HNED has collected a RTSP URL for this Live TV service. This RTSP URL gives all the 
information necessary to issue the appropriate RTSP method. Parameters required for the IGMP message will 
be acquired via the SETUP method from RTSP. 

7.1 .2 Live Content exposed witin SD&S 

Within SD&S, the Multicast IP address is exposed thanks to the "SingleService.ServiceLocation.IPMulticastAddress" 
XML element, with an optional "Source" attribute in case of source filtering. 

In case of RTSP, the URL is exposed thanks to the "SingleService.ServiceLocation.RTSPURL" XML element. 

For an example of a "Package" file and a "Broadcast" file, see clause 6.4. 
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7.2 Void 

7.3 Multicast Connection IVIanagement 

The DVB-IPTV handbook mandates IGMPv3 (RFC 3376 [i.5]) for the IPI-1 interface. What does it mean? 

7.3.1 IGlVIPvl 

IGMPvl (RFC 1 1 12 [i.6]) defines the following message: 

12 3 

012345S789012345S789012345S78901 

I Version I Type | Unused | Checksum | 

I Group Address | 

The 2 messages types (Type) are: 

• Host Membership Query, value=l. 

• Host Membership Report, value=2. 
As version is 1, this gives for the first octet: 

• Host Membership Query, value=Oxl 1 . 

• Host Membership Report, value=0xl2. 
The Unused field is set to zeroes. 

7.3.2 IGI\/IPv2 



defines the following message: 

















1 






2 




3 


01234567 


89012345678; 


5 C 


112345678901 


+-+-+-+-+-+-+-+-+-+-+- 


-+-+-+-+-+- 


- + - + - + - + - 


- + - 


■+-+-+-+-+-+- 


-+-+-+-+-+-+ 


1 Type 1 


Max 


Resp Time 


1 




Checksum 


1 


+-+-+-+-+-+-+-+-+-+-+- 


-+-+-+-+-+- 


-+-+-+-+- 


- + - 


■+-+-+-+-+-+- 


-+-+-+-+-+-+ 


1 




Group 


Address 






1 



The message Types values are: 

• 0x11 : Membership Query (General Query or Specific Query). 

• 0x16: v2 Membership Report. The IP packet is sent to eh specific multicast address. 

• 0x17: Leave Group. The IP packet is sent to the all routers group (224.0.0.2). 

The Max Resp Time field reflects the maximum time before sending a response for the host; this allows managing 
timers in a more efficient way. 
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7.3.3 IGMPv3 



IGMPv3 defines the following Membership Query message: 



12 3 

01234567890123456789012345678901 

I Type = 0x11 | Max Resp Code | Checksum | 

I Group Address | 

I Resv |S| QRV | QQIC | Number of Sources (N) | 

I Source Address [1] | 

+ - - + 

I Source Address [2] I 



I Source Address [N] | 

The Max Resp Code field is quite equivalent to the v2 Max Resp Time, with possibilities for more complex 
values. 

7.3.4 Impact is on the HNED 

In IGMPv3 (RFC 3376 [i.5]), clause 7.2.1 says: "In order to be compatible with older version routers, IGMPv3 hosts 
MUST operate in version 1 and version 2 compatibility modes". So having a DVB-IPTV compliant HNED means that 
it follows the IGMPv3 spec, meaning that it must conform to this statement. 

The detection of which version of IGMP runs on the router is done by looking at the Query message received: 

• IGMPvl Query: length = 8 octets AND Max Resp Code field is zero. 

• IGMPv2 Query: length = 8 octets AND Max Resp Code field is non-zero. 

• IGMPv3 Query: length > 12 octets. 

Thus it is possible that the HNED be connected to network with previous versions of IGMP, though such a 
configuration would not take advantage of IGMPv3 enhancement. 

7.4 RTSP Connection IVIanagement 

7.4.1 RTSP with SD&S 

This clause will present call flows for RTSP session management as announced from the SD&S metadata. The first 
example will be the simplest one, with only one RTSP address. The second example will involve EEC and RET flows 
that also need their own RTSP sessions. 
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7.4.1 .1 RTSP Session with one media flow 

The following service is announced via SD&S: 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 

xmlns :xsi="http : //www.w3 . org/2 01/XMLSchema- instance" > 

<BroadcastDiscovery DomainName="providerl . com" Version="0" > 
<ServiceList> 

<SingleService> 

[. . .] 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . Ill . 1 . 12" Port="8208" Source="192 . 100 . 100 . 50" 

Streaming="udp" /> 
<RTSPURL>rtsp : //live .providerl . com/Channel2 .mpg</RTSPURL> 
</ServiceLocation> 

<TextualIdentif ier DomainName= "providerl . com" ServiceName="Channel2"/> 
<DVBTriplet OrigNetId="0 " Serviceld="5002" TSId="202"/> 
<MaxBitrate>4000</MaxBitrate> 
</SingleService> 
<SingleService> 

[. . .] 
</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 

NOTE 1 : the operator can announce IP multicast concurrently with RTSP URL. This can be useful for example in 
the case of park upgrade where some old HNEDs cannot use RTSP while the new HNEDs use preferably 
RTSP. 

The following shows an example of message exchange between the HNED and the RTSP server. At first, the HNED 
may send a RTSP DESCRIBE to retrieve information about the service. 



DESCRIBE rtsp: //live. providerl .com/Channel2 .mpg RTSP/1.0 

CSeq: 1 

Accept: text/xml 



The DESCRIBE response from the server includes an XML structure that is in fact the Broadcast Offering for this 
service. 

RTSP/1.0 200 OK 

Cseq: 1 

Content -length: 1306 

Content-Type: text/xml 

Content-Encoding: UTF-8 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 

xmlns :xsi="http : //www.w3 .org/2 01/XMLSchema- instance" > 

<BroadcastDiscovery DomainName= "providerl . com" Version="0" > 
<ServiceList> 

<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . Ill . 5 . 44" Port="5502" Source=" 192 . 100 . 100 . 70 " 
Streaming="udp" /> 
</ServiceLocation> 

<TextualIdentif ier DomainName= "providerl . com" ServiceName="Channel2"/> 
<DVBTriplet OrigNetId="0 " Serviceld=" 5002 " TSId="202"/> 
<MaxBitrate>400 0</MaxBitrate> 
<SI ServiceType="01" PrimarySISource="XML" > 

<Name Language="ENG" >Channel 2 - SD</Name> 
<Name Language="FRA" >Canal 2 - SD</Name> 

<Description Language="ENG" >This is the channel 2 in SD</Description> 
<Description Language="FRA" >Ceci est le canal 2 en SD</Description> 
</SI> 
<AudioAttributes> 

< Coding href =" urn: mpeg:mpeg7 : cs :AudioCodingFormatCS :2001:3.2"> 

<Name>MPEG-l Audio Layer II</Name> 
</Coding> 
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<NumOf Channel s>2</NumOf Channel s> 
</AudioAttributes> 
<VideoAttributes> 

< Coding href =" urn: mpegimpeg? :cs iVisualCodingFormatCS :2001:2.2.2"> 

<Name>MPEG-2 Video Main Profile @ Main Level</Name> 
</Coding> 
</VideoAttributes> 
</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 



NOTE 2: In this example, the muhicast address retrieved from the RTSP DESCRIBE is not the same as the one 
originally announced within the Broadcast Offering. Of course it can also be the same. 

The HNED perform a SETUP for this service. In this example, only one SETUP is necessary since only one RTSP URL 
is exposed and only one media flow is sent on the network (the MPEG2-TS stream). 



SETUP rtsp: //live.providerl .com/Channel2 .mpg RTSP/1.0 

CSeq: 2 

Transport : RTP/AVP;multicast ;destination=224 . Ill . 5 . 44 ; source=192 . 10 . 10 . 70 ;port=5502-550 3 



RTSP/1.0 200 OK 

Cseq: 2 

Session: 12345678 ;timeout=60 

Transport : RTP/AVP ; mult least ;destination=224 . Ill . 5 . 44 ; source=192 .10 0.100. 70 ;port=5502-5503 



NOTE 3: In case there are multiple multicast addresses available for the service, the HNED can put several 

Transport headers in the SETUP request, in which case the server will answer with only one Transport 
header in the SETUP response, indicating the multicast address to be used by the HNED. 

Then the HNED sends the PLAY message to the server. In case of multicast, this does not perform the connection to the 
service, the IGMP Join message will do so. This informs the RTSP server that this HNED is connecting to this service. 
This can also inform intermediate devices of this connection. 



PLAY rtsp: //live.providerl .com/Channel2 .mpg RTSP/1.0 

CSeq: 3 

Session: 12345678 



RTSP/1.0 


200 OK 


















Cseq: 3 




















Session: 


12345678 


















RTP-Info 


url= rtsp 


//live 


providerl 


com/Channel2 


mpg 


seq= 


=11223344 


•rtptime= 


=10203040 



7.4.1 .2 RTSP Sessions with multiple media flows 

The following service is announced via SD&S. In this example, we use a minimal SD&S announce, all the information 
will be carried within the response to the DESCRIBE message. 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 

xmlns :xsi="http : //www.w3 . org/2 01/XMLSchema- instance" > 

<BroadcastDiscovery DomainName= "providerl . com" Version="0"> 
<ServiceList> 

<SingleService> 

[. . .] 
</SingleService> 
<SingleService> 

<ServiceLocation> 
<RTSPURL> 

rtsp : //live .providerl . com/Channel2 
</RTSPURL> 
</ServiceLocation> 

<TextualIdentif ier DomainName= "providerl . com" ServiceName="Channel2"/> 
<DVBTriplet OrigNetId=" " Serviceld="5002" TSId="202"/> 
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<MaxBitrate>4000</MaxBitrate> 
</SingleService> 
<SingleService> 

[. . .] 



</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 



The following shows an example of message exchange between the HNED and the RTSP server. At first, the HNED 
may send a RTSP DESCRIBE to retrieve information about the service. 

DESCRIBE rtsp: //live.providerl .com/Channel2 RTSP/1.0 

CSeq: 1 

Accept: text/xml 

The DESCRIBE response from the server includes an XML structure that is in fact the Broadcast Offering for this 
service. 

RTSP/1.0 200 OK 

Cseq: 1 

Content -length: 1847 

Content-Type: text/xml 

Content -Encoding: UTF-8 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns=" urn :dvb: metadata : iptv: sdns : 2008-1" 

xmlns :xsi="http : //www.w3 . org/2 001/XMLSchema- instance" > 

<BroadcastDiscovery DomainName="providerl . com" Version=" 0" > 
<ServiceList> 

<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . 222 . 2 . 16" Port="8208" Source="192 . 100 . 100 . 20" 
Streaming="rtp" FECMaxBlockSizePackets="8" FECMaxBlockSizeTime="10 0" 
FECOTI = "MDB j MTA1MDE= " > 

<FECBaseLayer Address="224 . 222 . 2 . 16" Port="8210" 
Source="192 .100. 100. 20" MaxBitrate="200" 

RTSPControlURL="rtsp: //live.providerl . com/Channel2?FecBase" /> 
<FECEnhancementLayer Address="224 . 222 . 3 . 16" Port="4304" 
Source="192 .100. 100. 20" MaxBitrate="200" 

RTSPControlURL="rtsp : //live .providerl . com/Channel2?FecEnhancement" /> 
</IPMulticastAddress> 
<RTSPURL RTSPControlURL="rtsp: //live.providerl . com/Channel2?Media" > 

rtsp : //live .providerl . com/Channel2 
</RTSPURL> 
</ServiceLocation> 

<TextualIdentif ier DomainName= "providerl . com" ServiceName="Channel2"/> 
<DVBTriplet OrigNetId=" " Serviceld=" 5002 " TSId="202"/> 
<MaxBitrate>40 0</MaxBitrate> 
<SI ServiceType="01 PrimarySISource="XML" > 

<Name Language="ENG" >Channel 2 - SD</Name> 
<Name Language="FRA" >Canal 2 - SD</Name> 

<Description Language="ENG" >This is the channel 2 in SD</Description> 
<Description Language="FRA" >Ceci est le canal 2 en SD</Description> 
</SI> 
<AudioAttributes> 

< Coding href =" urn: mpeg:mpeg7 : cs : AudioCodingFormatCS :2001:3.2"> 

<Name>MPEG-l Audio Layer II</Name> 
</Coding> 

<NumOf Channel s>2</NumOf Channel s> 
</AudioAttributes> 
<VideoAttributes> 

< Coding href =" urn: mpeg:mpeg7 : cs :VisualCodingFormatCS :2001:2.2.2"> 

<Name>MPEG-2 Video Main Profile @ Main Level</Name> 
</Coding> 
</VideoAttributes> 
</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 
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The HNED perform then several SETUP for this service: one SETUP is needed for each flow, i.e. one for the media 
flow (using the RTSPControlURL of the media flow), and one for each FEC layer (using the RTSPControlURL of the 
EEC layers). If the HNED does not want to connect to a flow, it will not issue the corresponding SETUP command. In 
this example, the HNED will only connect to the media flow and to the FEC Base layer. 



SETUP rtsp: //live. providerl .com/ Channel2?Media RTSP/1.0 

CSeq: 2 

Transport : RTP/AVP ; mult least ;destination=224 .222 .2 . 16 ; source=192 .10 0.100 . 20 ;port=8208-8209 



RTSP/1.0 200 OK 

Cseq: 2 

Session: 12345678 ;timeout=60 

Transport : RTP/AVP ; mult least ;destination=224 .222 .2 . 16 ; source=192 .10 0.100 . 20 ;port=8208-8209 



SETUP rtsp 


//live .providerl . 


com/Channel2?FecBase 


RTSP/1 



















CSeq: 3 






























Session: 12345678 




























Transport : 


RTP/AVP 


multicast 


/destination^ 


= 224 


222 


2.16; source 


= 192 


100 


100 


20 


•port = 


= 8210 


-8211 



RTSP/1.0 200 OK 

Cseq: 3 

Session: 12345678 ;timeout=60 

Transport : RTP/AVP ; mult least ;destination=224 .222 .2 . 16 ; source=192 .10 0.100 . 20 ;port=8210-8211 



Then the HNED sends the PLAY message to the server. Only one PLAY is needed for both flows. In case of multicast, 
this does not perform the connection to the service, the IGMP Join message(s) will do so. This informs the RTSP server 
that this HNED is connecting to this service with the specific SETUP as previously performed. This can also inform 
intermediate devices of this connection. 



PLAY rtsp: //live. providerl .com/Channel2 RTSP/1.0 

CSeq: 4 

Session: 12345678 



RTSP/1.0 


200 OK 


Cseq: 4 




Session: 


12345678 


RTP-Info 


url=rtsp: //live. providerl . com/Channel2?Media; seq=1122 3 344 ;rtptime=102 3 04 , 


url=rtsp 


//live .providerl . com/Channel2?FecBase; seq=55667788 ;rtptime=50607080 



7.5 Transport of the stream 



The video content is streamed using an MPEG-2 transport stream, as defined in TS 101 154 [2], which is then 
encapsulated in RTP/UDP or directly in UDP. Usually a Single Program Transport Stream (SPTS) is used as only the 
bandwidth for the selected content is needed. However Multi Program Transport Streams (MPTS) are not out ruled. 

The information if RTP/UDP or UDP encapsulation is used is provided by the SD&S Broadcast Discovery record 
attribute IPMulticastAddress® Streaming or the BCG locator for multicast services and by the RTSP transport header 
for unicast services: 

• A IPMulticastAddress® Streaming value of "rtp" indicates RTP/UDP encapsulation. 

• A IPMulticastAddress® Streaming value of "udp" indicates direct UDP encapsulation. 

In case the IPMulticastAddress@Streaming attribute is not defined in the SD&S record RTP/UDP encapsulation is 
assumed. 

A RTSP transport header of "RTP/AVP/UDP" indicates RTP/UDP encapsulation. A RTSP transport header of either 
"MP2T/H2221/UDP" or "RAW/RAW/UDP" indicates direct UDP encapsulation. 
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8 Typical applications available within the scope of the 

DVB-IPTV phase 1 handbook 

DVB-IPTV Phase 1 is a significant step in standardizing entertainment video over IP home network; however, it does 
not cover all possibilities or areas for standardization. This clause attempts to outline its boundaries with the belief that 
future versions of the standard will extend the scope. 

The boundaries can be broken down into a number of areas: 

• Audio/Video transport and codecs. 

• Topology. 

• Networking Addressing and Discovery. 

• Network Level Security. 

• Operation over different physical networks and Quality of Service. 

• DNG/HNED only networks. 

8.1 Video transmission and codecs 

The current version of the DVB-IPTV handbook only addresses the use of an MPEG-2 transport stream for the delivery 
of content. It does not address separation of the transport stream into elementary streams or any other carrier other than 
the MPEG2 transport stream. 

The transport over IP is via RTP and UDP or via UDP directly (without RTP). For the later the network has to ensure 
that no packet reordering occurs. 

In case of RTP encapsulation a single PCR per MPTS should be used. 

AL-FEC is only supported with RTP/UDP encapsulation. It is not supported for direct UDP encapsulation of the 
transport stream. 

Supported media formats are given in TS 101 154 [2]. 

8.2 Topology 

The current version of the DVB-IPTV handbook is limited to the following simple in-home network topologies: 

• DNG/HNED Only Networks. 

• Single Segment Home Networks with single address space and single DHCP server. 

These are quite restrictive topologies but simple enough to satisfy the majority of current uses cases. This means that a 
network consisting of two DNGs in the home must be on independent and unconnected network segments. 

8.3 Networking Addressing and Discovery 

The standard uses DHCP to obtain network addressing and several other pieces of information but the option table is 
deliberately short to make client implementation simple in the HNED. However the implementation does use the new 
server message outlined in RFC 3203 [i.2] "FORCERENEW" which is not usually implemented in most DHCP servers. 

The DHCP message also requires a unique identifier so the reuse of MAC addresses by whatever method is not 
allowed. 

The DHCP server non-availability has been designed to be an unusual occurrence so whilst the use of RFC 3927 [i.l] is 
recommended in emergency, temporary situations; a DHCP server will be required for a DVB-IPTV home network to 
function normally. 
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8.4 Network Level Security 

Network level security, for example, denial of service attacks are not covered in the DVB-IPTV handbook. 

8.5 Operation over different physical networks and Quality of 
Service 

The design of DVB-IPTV Phase 1 is physical layer independent and relies on the IP network to provide the required 
quality of service. The DVB-IPTV specifications are easily met on most wired networks but less so by in-home wireless 
networks, particularly 802. 11 networks. 

The DVB-IPTV handbook defines only the user priority classes for the different traffic types and the related DSCP and 
IEEE 802. Id [i.4] priority values. No QoS enforcement mechanisms are defined. 

8.6 DNG/HNED Only Networks 

The requirement for a combination of DNG/HNED e.g. a DSL modem combined with a set-top box, means that the 
DVB-IPTV handbook phase 1 treats this box as effectively a DNG and this is outside of the scope of the specification. 

However, if this box has any Ethernet or other interface capable of providing a network for example 
IEEE 802.11a/g [i.3] wireless LAN then it falls under the specification of DVB-IPTV. 
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